A good notation has subtlety and suggestiveness which at times makes it almost seem like a live teacher.
A good notation has subtlety and suggestiveness which at times makes it almost seem like a live teacher.
Les étudiants qui découvrent le langage, mes collègues enseignants qui cherchent un document de cours et d’exercice accessible, et … moi-même (pour organiser mes notes diverses)!
Si vous appartenez à l’une de ces catégories, ce livre n’est pas pour vous :
Ce document est la compilation de plusieurs années d’enseignement de SysML depuis 2007, que ce soit :
Vous trouverez en référence (cf. Bibiliographie) les ouvrages et autres documents utilisés.
Ce document a été réalisé de manière à être lu de préférence dans sa version électronique, ce qui permet de naviguer entre les références et les renvois interactivement, de consulter directement les documents référencés par une URL, etc.
|
|
Si vous lisez la version papier de ce document, ces liens clickables ne vous servent à rien, et c’est votre punition pour avoir utilisé du papier au lieu du support électronique! |
J’ai utilisé un certain nombre de conventions personnelles pour rendre ce document le plus agréable à lire et le plus utile possible, grâce notamment à la puissance d’AsciiDoc :
Dernière MAJ : 30/11/2012 - 13:40:32 CET
Document généré par Jean-Michel Bruel via AsciiDoc (version 8.6.8) de Stuart Rackham.
La version présentation a été générée en utilisant W3C HTML Slidy © de Dave Raggett, amélioré par Jean-Michel Inglebert.
Pour l’instant ce document est libre d’utilisation et géré par la Licence Creative Commons.
licence Creative Commons Paternité - Partage à l'Identique 3.0 non transposé.
N’hésitez pas à m’envoyer vos remarques en tout genre en m'écrivant ici.
Everything should be made as simple as possible, but not simpler.
Mon approche pédagogique repose sur plusieurs principes bien établis :
Par exemple certains diagrammes sont abordés plusieurs fois (comme le diagramme paramétrique). Le lecteur pourra avoir une impression de redite par moment. Sauf erreur de ma part (toujours possible!), c’est volontaire. En général les répétitions vont en niveau de précision, de détails et de complexité croissant.
Dans la mesure du possible, j’essaye de donner des exemples aux principes énoncés.
Les définitions ou autres affirmations sont tirées d’ouvrages de référence généralement citées.
J’aime réaliser une "carte" [1] qui sert à "placer" les différents concepts abordés. Il me semble que cela permet aux étudiants de raccrocher les nouveaux concepts aux précédents.
A part le chapitre d’UML à SysML, aucune connaissance particulière d’UML n’est nécessaire. Il s’agit d’un partie pris prenant en compte plusieurs points :
Si vous ne deviez lire qu’un seul chapitre, voilà ce qu’il faudrait retenir…
include:fiche.txt[]
SysML, c’est :
bdd)
ibd)
par)
pkg)
seq)
act)
uc)
st)
SysML, c’est (suite):
req)
SysML, ce n’est pas :
Si vous utilisez cet ouvrage dans le cadre du bac STI2D qui a introduit depuis 2011 la notation SysML au programme, nous donnerons ici (bientôt) des conseils sur l’utilisation de ce cours [2].
L’objectif en STI2D n’est pas de former des spécialistes de SysML mais de permettre à tous d’apprendre une notation pour la modélisation de système qui se veut universelle. Il ne faut donc pas viser la complétude ou même demander trop de détails. La logique de la démarche de modélisation et l’importance de la communication devront primer.
A l’heure où nous écrivons ces lignes, il est également prévu de l’enseigner en classe prépa dès 2013.
L’exemple de système qui sera modélisé tout au long de ce livre en guise d’exemple est l’exemple d’un système de gestion et de supervision de crise. Les détails sont donnés en annexe (cf. Annexes).
Il existe un certain nombre d’autres exemple complets :
La matrice qui nous servira de "carte de base" pour placer les activités ou les modèles, sera celle-ci :
| Requirements | Structure | Comportement | Transverse | |
|---|---|---|---|---|
Organisation |
||||
Analyse |
||||
Conception |
||||
Implémentation |
Dans un axe horizontal, j’ai différencié quatre grands points de vue :
Les exigences et leur prises en compte sont un éléments critique pour le succès du développement du système. Sans explorer l’ensemble des activités d’ingénierie système (ce qui nécessiterait tout un volume du type de [reqs]) nous insisterons beaucoup sur cet aspect qui est souvent à l’origine de l’intérêt de SysML.
La description de l’architecture et des éléments constitutifs du système, avec les blocs, leurs relations, organisations internes, etc. constituera un point de vue important. C’est souvent la partie de SysML qui pose le moins de problème aux débutants.
Le comportement d’un système est du point de vue de l’utilisateur final beaucoup plus important que la structure elle-même. C’est la partie qu’il est la plus à même d’exprimer, de comprendre (vos modèles) et de valider.
Un certains nombre de concepts sont transverses aux trois points de vue précédents. Il s’agira principalement de parler de cohérence entre les phases de développement ou entre les points de vue.
Dans un axe vertical, j’ai différencié quatre grandes phases du cycle de vie du développement :
Une étape indépendante du type de cycle de développement envisagé (en V, agile, etc.) mais qui concerne la mise en place d’un cadre de travail qui permette un développement de qualité (outils, éditeurs, gestionnaire de version, de tâches, etc.)
Cette phase vise plutôt à examiner le domaine du problème. Elle se focalise sur les cahiers des charges et les exigences. L’analyse débouche sur un dossier d’analyse qui décrit les grandes lignes (cas d’utilisation, architecture principale) du système.
Cette phase vise plutôt à examiner le domaine de la solution. Elle débouche sur un dossier de conception qui décrit les détails conceptuels de la solution envisagée (structure détaillée, comportement, etc.)
Cette phase traite des développements finaux (construction ou approvisionnement en matériel, développement de codes, etc.).
Enseignant en informatique, je me retrouve souvent à enseigner SysML à des informaticiens. D’où ce petit exposé sur mon opinion de la différence entre les deux "mondes".
Que ce soit généralement en terme de cycle de développement ou historiquement, l’Ingénierie Système arrive avant l’Ingénierie Logicielle. Les ingénieurs systèmes ont donc une longue expérience et des pratiques bien ancrées.
On parle de système complexe lorsque l’on a affaire à :
Toute la question que l’Ingénierie Système cherche à résoudre est : comment passer des exigences au système de la façon la plus efficace possible.
Pour cela l’Ingénierie Système est découpée en plusieurs analyses, chacune avec un but bien particulier :
Pour arriver à combler le gap entre le système à développer et ses spécifications.
Il existe un grand nombre de standards en Ingénierie Système . Cette section fera (bientôt) une revue de ces différents standards et organismes et de leur utilisation (IEEE, EIA, ISO, certification, NASA, INCOSE, AFIS, …).
Enfin, citons un rapport de 2010, le Rapport Potier, qui présente l'état des logiciels embarqués et qui sera utiles à ceux qui s’intéressent aux verrous technologiques liés à ce domaine.
L’Ingénierie Système génère beaucoup de documentation. Les processus de certification (par exemple dans l’aéronautique) sont encore basés sur des documents textuels.
Vue la complexité grandissante des systèmes, petit à petit cette ingénierie tente de passer d’une ingénierie centrée documents à une ingénierie centrée modèles. D’où l’importance de se poser la question des notations et langages pour réaliser et communiquer avec ces modèles (cf. [Notation]).
L’ingénierie des exigences est d’une importance capitale en Ingénierie Système . Nous renvoyons pour l’instant le lecteur au cours de Master qui précède ce cours.
Liens avec AADL, …
Liens avec la V&V
SysML n’est pas une méthode. En effet aucune démarche n’est imposée pour l’utilisation des diagrammes, l’ordre logique dans lesquels il vaut mieux les réaliser, etc. La spécification ne porte que sur la notation elle-même. D’où le pluriel dans le titre de cette section : il existe presque autant de méthodes que d’entreprise développant des systèmes. Nous nous contenterons de donner ici quelques heuristiques (cf. Annexe Considérations méthodologiques pour la présentation de quelques méthodes bien identifiées) :
Un diagramme ne doit pas être considéré comme définitif. Il peut être complété alors que l’on traite un autre aspect de la modélisation (exemple classique : ajout d’un nouveau block lors de la réalisation d’un diagramme de séquence). Quelque soit la démarche adoptée elle doit être itérative et permettre de revenir sur les premières étapes.
Bien intégrer les niveaux d’abstraction dans votre démarche. SysML possède certaines constructions pour formaliser cet aspect (Packages par exemple). Nous matérialisons cet aspect par la partie verticale de la matrice (cf. [Matrice]).
|
|
Bien intégrer les niveaux d’abstraction dans votre démarche. SysML possède certaines constructions pour formaliser cet aspect (Packages par exemple). Nous matérialisons cet aspect par la partie verticale de la matrice (cf. [Matrice]). |
N’essayez pas de réaliser tous les diagrammes possibles pour votre système. Réalisez uniquement ceux qui sont utiles à votre cas particulier.
Il existe une notation qui se veut "unifiée" pour les modèles : UML. Néanmoins cette notation est peu adaptée pour l’Ingénierie Système :
En conclusion UML est une bonne base :
Mais…
classe ou d'héritage par exemple)
|
|
Versions de la spécification de SysML
La version 1.0 du langage de modélisation SysML a été adoptée officiellement par l’OMG le 19 septembre 2007. Depuis, trois révisions ont été réalisées : |
American Systems, BAE Systems, Boeing, Deere & Company, EADS Astrium, Eurostep, Israel Aircraft Industries, Lockheed Martin, Motorola, NIST, Northrop Grumman, oose.de, Raytheon, Thales, …
Artisan, EmbeddedPlus, Gentleware, IBM, Mentor Graphics, PivotPoint Technology, Sparx Systems, Vitech, …
AP-233, INCOSE, Georgia Institute of Technology, AFIS, …
SysML n’est pas une palette de dessins et d'éléments de base servant à faire des diagrammes. Il existe une représentation graphique des éléments modélisés en SysML. Elle est importante car elle permet de communiquer visuellement sur le système en développement, mais du point de vue du concepteur, c’est le modèle qui importe le plus.
Pour ceux qui cherchent à étudier un diagramme en particulier voici un plan de cette section (nous utilisons ici le "plan" vu lors de l’introduction de la [Matrice]) :
| Requirements, cf. [reqs] | Structure, cf. [archi] | Comportement, cf. [behavior] | Transverse, cf. [transvers] | |
|---|---|---|---|---|
Organisation, cf. [orga] |
|
|
|
|
Analyse, Conception, Implémentation [4] |
|
|
|
|
Il existe un certain nombre d’outils permettant de réaliser des modèles SysML. Voici une liste non exhaustive :
include:outils.txt[]
Vous trouverez sur Internet des comparatifs et des avis à jour sur les outils.
Ce que je voudrai souligner ici c’est l’importance du modèle comme "dépôt" (je préfère le terme anglais de repository) d'éléments de base en relation les uns avec les autres. C’est toute la différence entre le dessin et le modèle.
|
|
Attention toutefois à ne pas confondre ce que vous permet (ou pas) de faire l’outil et la notation elle-même. Les fabricants ont parfois pris des libertés ou bien n’ont pas complètement implémenté toutes les subtilités de la notation. |
Abordons quelques principes généraux de SysML.
req, act, bdd, ibd, sd, etc.)
Dans l’exemple ci-dessous, le diagramme "Context_Overview" est un Block Definition Diagram (type bdd) qui représente un
package, nommé "Context".
| Requirements | Structure | Comportement | Transverse | |
|---|---|---|---|---|
Organisation |
||||
Analyse |
||||
Conception |
||||
Implémentation |
On abordera :
|
|
Espace de nommage
Dans un package, on n’a pas à se soucier des noms des éléments. Même si d’autres utilisent les mêmes noms, il n’y aura pas ambiguité. |
Les modèles peuvent être organisés selon toutes sortes de considération (cf. [organisation]). Le mécanisme qui permet de les organiser est le package (paquetage).
Il existe plusieurs types de package :
un package "top-level" dans une hiérarchie de package
le type le plus classique : un ensemble d'éléments de modèles
un package prévu pour être réutilisé (importé) par d’autres éléments
un package spécial pour représenter les points de vue
Les modèles peuvent être organisés selon toutes sortes de considération :
|
|
Organisation par défaut
L’outil TOPCASED propose, lors de la création d’un premier modèle, de créer une organisation "type" par défaut. +
+ |
Un package est un espace de nommage pour tous les éléments qu’il contient.
|
|
Dans les outils SysML, vous pouvez demander à voir les noms complets (Qualified names)
des éléments, c’est à dire le nom de l'élément prefixé par son (ou ses) package(s)
(e.g., |
Un certain nombre de dépendances peuvent exister entre des éléments de package ou entre les packages eux-mêmes :
une dépendance "générale", non précisée,
représentée par une simple flèche pointillée ----->
l'élément "utilise" celui à l’autre bout de la flèche (un type par exemple),
représentée par le stéréotype << use >>
l'élément est un raffinage (plus détaillé) de celui à l’autre bout de la flèche,
représentée par le stéréotype << refine >>
l'élément est une "réalisation" (implémentation) de celui à l’autre bout de la flèche,
représentée par le stéréotype << realize >>
l'élément (e.g., une activité ou un requirement) est "alloué" sur celui à l’autre bout de la flèche (un block la plupart du temps),
représentée par le stéréotype << allocate >>
| Requirements | Structure | Comportement | Transverse | |
|---|---|---|---|---|
Organisation |
||||
Analyse |
||||
Conception |
||||
Implémentation |
On abordera :
|
|
L’ingénierie des exigences est une discipline à part entière et nous n’abordons ici que les aspects en lien avec la modélisation système. Voir le livre de référence pour plus de détails ([Sommerville1997]) ou le guide de l’AFIS ([REQ2012]). |
Comme nous l’avons vu pour les packages, plusieurs types d’organisations sont possibles :
Les requirements sont généralement stockés dans des feuilles excel.
Il est possible d’indiquer un certain nombre de propriétés sur un requirement :
high, low, …)
stakeolder, law, technical, …)
high, low, …)
proposed, aproved, …)
analysis, tests, …)
Les principales relations entre requirement sont :
pour décrire la décomposition d’un besoin en plusieurs sous-besoins (⊕–)
pour décrire un ajout de précision (<<refine>>)
pour indiquer une différence de niveau d’abstraction (<<deriveReqt>>), par exemple
entre un système et un de ses sous-systèmes
Il existe ensuite les relations entre les besoins et les autres éléments de modélisation
(les block principalement) comme <<satisfy>> ou <<verify>>, mais nous les aborderons
dans la partie transverse.
Quelques exemples de req tirés de http://www.uml-sysml.org/sysml :
Une fois que les requirements ont été définis et organisés, il est utile de les lier au moins aux use cases
(en utilisant <<refine>> par exemple) et aux éléments structurels (en utilisant <<satisfy>> par exemple), mais ceci
sera abordé dans la partie transverse.
|
|
Chaque requirement doit être relié à au moins un use case (et vice-versa!). |
Il est possible d’annoter les éléments de modélisation en précisant les raisons (rationale) ou les éventuels problèmes anticipés (problem).
Bien que nous traitions les cas d’utilisation dans la partie comportement, nous les abordons ici du fait de leur proximité avec les requirements.
Ce diagramme est exactement identique à celui d’UML.
|
|
Un acteur représente un rôle joué par un utilisateur humain. Il faut donc plutôt raisonner sur les rôles que sur les personnes elles-mêmes pour identifier les acteurs. |
| Requirements | Structure | Comportement | Transverse | |
|---|---|---|---|---|
Organisation |
|
|||
Analyse |
|
|
|
|
Conception |
|
|||
Implémentation |
|
| Requirements | Structure | Comportement | Transverse | |
|---|---|---|---|---|
Organisation |
||||
Analyse |
||||
Conception |
||||
Implémentation |
On abordera :
En terme d’organisation, le mécanisme clef est celui de package. Celui-ci va permettre d’organiser les modèles, pas le système lui-même. Nous avons abordé cette organisation ici.
Pour l’organisation du système, on trouve le plus souvent :
Un bdd peut représenter :
Un diagramme de block décrit les relations entre les blocks (composition, généralisations, …). Ce diagramme utilise les mêmes éléments que le diagramme de classe UML.
Un block est constitué d’un certain nombre de compartiments (Compartments) :
Equivalent UML des propriétés (e.g., attributs)
Les méthodes supportées par les instances du bloc.
Les contraintes
Les allocations
Les exigences liées à ce bloc.
On peut définir ses propres compartiments
On peut différencier 3 types de propriétés d’un block :
Les éléments qui composent le block (cf. [ibd])
Des caractéristiques (quantifiables)
Les éléments auquel le block a accès (via des associations ou des agrégations)
|
|
Les values sont ce qui se rapproche le plus des attributs de classes UML. |
Pour typer les valeurs, SysML propose de définir des Value Types.
Il existe deux types de relations entre blocs :
Un ibd décrit la structure interne d’un bloc sous forme de :
Les parties qui constituent le système (ses sous-systèmes)
Elément d’interaction avec un block
Liens entre ports
Les parties sont représentés par les éléments au bout d’une composition dans un bdd.
Elles sont créés à la création du block qui les contient et sont détruites avec lui s’il
est détruit (dépendance de vie).
|
|
Il ne s’agit pas de redessiner le BDD. Les parts sont des instances et non des classes (au sens objet). |
On représente les parts comme des block en traits pleins et les references comme des blocks en trait pointillés.
Les ports :
|
|
Les ports définissent les points d’interaction offerts ( |
Les ports de type Flux peuvent être :
|
|
Un flow port atomique ne spécifie qu’un seul type de flux en entrée ou en sortie (ou les deux), la direction étant simplement indiquée par une flèche à l’intérieur du carré représentant le port. Il peut être typé par un block ou un Value Type représentant le type d’élément pouvant circuler en entrée ou en sortie du port. |
Ce diagramme utilise 3 concepts clefs :
ibd)
C’est un block particulier :
≪constraint≫ (au lieu de block)
C’est une forme particulière de Internal Block Definition
Les diagrammes de séquence système (DSS) sont des Sequence Diagrams UML classiques où seul le système est représenté comme une boîte noire en interaction avec son environnement (les utilisateurs généralement).
Il permet de décrire les scénarios des cas d’utilisation sans entrer dans les détails. Il convient donc mieux à l’ingénierie système qu’un diagramme de séquence classique (cf. section sur les seq).
En résumé, il existe plusieurs diagrammes permettant d’exprimer la structure du système à concevoir. En fonction du niveau de détail nécessaire on peut voir les sous-systèmes comme des boîtes noires (des blocks) ou comme des boîtes blanches (grâce à l'ibd correspondant).
→), une composition (losange noir) et l’agrégation (losange blanc)?
| Requirements | Structure | Comportement | Transverse | |
|---|---|---|---|---|
Organisation |
||||
Analyse |
||||
Conception |
||||
Implémentation |
On abordera :
Les éléments de base :
les principaux acteurs (leur rôle) qui participent (on parle parfois d’acteurs principaux) ou qui bénéficient (on parle alors d’acteurs secondaires) du système.
représente un ensemble d’actions réalisées par le système intéressant pour au moins un acteur
participation d’un acteur à un cas d’utilisation.
|
|
Un acteur représente un rôle joué par un utilisateur humain. Il faut donc plutôt raisonner sur les rôles que sur les personnes elles-mêmes pour identifier les acteurs. |
Le Diagramme des Cas d’Utilisation est un diagramme UML permettant de représenter :
|
|
On notera simplement |
Un cas d’utilisation représente un ensemble de scénarios que le système doit exécuter pour produire un résultat observable par un acteur.
Retrait par carte bancaire
L’UC démarre lorsque le Guichet Automatique Bancaire (GAB) demande au client son numéro confidentiel après l’introduction de sa CB. Le client entre son code et valide son entrée. Le GAB contrôle la validité du code. Si le code est valide, le GAB autorise le retrait et l’UC se termine.
Le client peut à tout instant annuler l’opération. La carte est éjectée et l’UC se termine.
UC01 ou RetraitCB (pour Retrait par carte bleue)
Un cas d’utilisation peut être précisé par :
|
|
Dans les outils, cette "précision" se manifeste par le fait que l’on "attache"
généralement un diagramme de séquence à un cas d’utilisation (clic droit sur un Use Case → nouveau |
Un acteur peut être une personne, un ensemble de personnes, un logiciel, un processus qui interagit avec un ou plusieurs UC.
On peut trouver plusieurs types d’acteurs :
actor Diagramme d’UC ci-après)
<<utility>>
<<process>>
<<thread>>
|
|
On peut utiliser des liens de généralisation/spécialisation entre acteurs pour représenter les possibilités pour le spécialisé d’avoir les mêmes prérogatives (notamment en terme d’utilisation du système) que le généralisé. |
En général, une simple association relie acteurs et Use Case. On peut également orienter ces associations.
Après avoir lister les cas d’utilisation, il est utile de les organiser et de montrer les relations entre eux. Plusieurs relations sont possibles :
<<extend>>)
Indique que le Use Case source est éventuellement exécutée en complément du Use Case destination (cas particulier, erreur…)
<<include>>)
Indique que le Use Case est inclus obligatoirement dans un autre Use Case (notion de sous-fonction par exemple)
Relation entre un Use Case général et un autre plus spécialisé qui hérite de ses caractéristiques et en rajoute (différents modes d’utilisation d’un système par exemple)
|
|
On n’utilise généralement |
|
|
Certains méthodologistes (comme T. Wielkins) préconisent de ne pas utiliser les acteurs et les cas d’utilisation (cf. son blog) |
Il permet de :
Les éléments qui composent ce diagramme sont :
les éléments en interaction (des blocks généralement)
des lignes verticales qui permettent d’indiquer un départ ou une arrivée d’interaction
pour matérialiser quand l'élément est actif
ce qui "circule" d’un élément à l’autre (signal, appel de méthode, …)
|
|
Les participants (et leur ligne de vie) représentent des instances de blocks (souvent "anonymes"). |
On peut également représenter des instructions itératives et conditionnelles au travers de cadres d’interaction :
loop (boucle)
alt (alternative)
opt (optionel)
par (parallèle)
region (région critique - un seul thread à la fois)
|
|
On utilise le diagramme de séquence pour représenter des algorithmes et des séquencements temporels. Lorsque le comportement se rapproche plus d’un flot, on utilise le diagramme d’activité (cf. section sur le act). |
La décomposition hiérarchique permet une description "TOP-DOWN" du système à réaliser.
On fait un Diagramme de Séquence Système pour chaque cas d’utilisation (issu du Diagramme d’UC) pour déterminer les échanges d’informations entre l’acteur et le système.
Ensuite on fait un Diagramme de Séquence (DS) pour décrire comment les blocks composant le système (issus du bdd) collaborent pour réaliser le traitement demandé.
To be completed…
To be completed…
En résumé…
Pour réviser…
| Requirements | Structure | Comportement | Transverse | |
|---|---|---|---|---|
Organisation |
||||
Analyse |
||||
Conception |
||||
Implémentation |
On abordera ici les aspects transversaux comme :
|
|
Chaque requirement doit être relié à au moins un use case (et vice-versa!). |
Nous avons vu déjà un certain nombre de mécanismes SysML qui permettent de tracer les exigences.
Nous les regroupons ici dans une matrice spécifique (qui se lit dans le sens des relations, par exemple un élément de structure comme un block <<satisfy>> une exigence).
| Requirements | Structure | Comportement | |
|---|---|---|---|
Requirements |
|
||
Structure |
|
|
|
Comportement |
|
XXX Mettre un exemple avec tous ces liens.
Un mécanisme nouveau en SysML et important pour l’Ingénierie Système est le mécanisme d'allocation. Il permet de préciser quel élément conceptuel (comme un comportement ou une activité) est alloué sur quel élément physique.
Il est possible d’exprimer cette allocation de plusieurs manières.
Parler du <<AllocatedTo>>, compartiments des blocks et autres annotations.
Parler des zones d’allocation dans les machines à états où les diagrammes d’activités par exemple.
Parler des <<allocate>>.
Placez dans un diagrammes des cas d’utilisation les différents acteurs et cas correspondant à l'étude de cas suivante (en indiquant les relations) :
Pour faciliter sa gestion, un entrepôt de stockage envisage de concevoir un système permettant d’allouer automatiquement un emplacement de stockage pour chaque produit du chargement des camions qui convoient le stock à entreposer. Lors de l’arrivée d’un camion, un employé doit saisir dans le système les caractéristiques de chaque article ; le système produit alors une liste où figure un emplacement pour chaque article. Lors du chargement d’un camion les caractéristiques des articles à charger dans un camion sont saisies par un employé afin d’indiquer au système de libérer les emplacements correspondant.
<<satisfy>> et <<allocate>> ?
Nous allons aborder le développement complet de notre exemple fil rouge en suivant une démarche classique et simple (utilisée par exemple dans [SeeBook2012], où proche de la démarche globale enseignée dans nos cous de DUT Informatique, ou encore proche des documents de référence en la matière [HAS2012], [KAP2007],[FIO2012]) :
Nous partirons du modèle des exigences produit initialement. Mais avant tout, parlons outils.
Nous sommes des défenseurs des principes [DRY] et [TDD]. Nous allons donc réaliser nos diagrammes dans un outil et non "à la main" (de simples dessins).
Nous choisissons ici l’outil TOPCASED pour des raisons que nous expliquerons ailleurs. La version utilisée pour réaliser les exemples de cette section
est la version 5.2.
Un outil SysML seul ne suffit pas (cf. Outillage). Il faut penser à la documentation (cf. Génération de doc).
Il existe de nombreux outils SysML. Nous renvoyons le lecteur sur le site de SysML-France pour des informations sur les dernières versions des outils.
Fortement liée aux outils, la possibilité d’animer les modèles ou encore d’effectuer des simulations est une exigence de plus en plus forte des ingénieurs systèmes.
Il existe de nombreuses possibilités. Citons par exemple :
L’outil RTaW propose, via génération de code VHDL de simuler les modèles. Voir une démonstration
ici.
L’outil Rhapsody possède une interface très pratique pour faire du prototypage rapide.
Voir mon tutoriel (en anglais) disponible ici.
L’outil Artisan permet également de faire de l’animation de modèles.
Il s’agit ici de décrire le contexte et d’identifier les principaux cas d’utilisation du système.
Chaque cas d’utilisation sera précisé (seq et act).
Les données métier seront alors identifiées pour construire le modèle d’architecture logique (bdd et ibd) complété par la description des comportements complexes (st).
Enfin le modèle d’architecture physique permettra de déterminer les aspects déploiement et constructions physiques d'équipements/
Afin de consolider les différents modèles, les liens de traçabilité qui n’auront pas été déjà décrit [5] seront rajoutés en insistant sur les liens :
Nous insistons dans l’ensemble de nos formations sur les approches test-driven, alors nous montrons dans cette section comment participer à la qualité du développement d’un système en formalisant (par exemple avec des diagrammes de séquence de scénarios à éviter) les test et les jeux de test.
La plupart des ouvrages sur un langage enseignent les éléments de ce langage, comme nous l’avons fait à la partie précédente. Nous allons ici partir du principe inverse : comment modéliser tel ou tel partie ou vue de mon système avec SysML. Un peu à la manière des ouvrages du type Cookbook, nous allons donner une liste non exhaustives de recettes. Les choix des éléments de modélisation sont arbitraires ou tirés de discussions (comme ce sera mentionné si c’est le cas).
C’est conseillé. Un block System permet de raccrocher tous les éléments qui le composent à un même niveau.
Dans l’exemple ci-dessous le système (le bloc Pacemaker) est lui-même un simple composant d’un élément de plus haut niveau : le contexte du système (le bloc Context) qui relie alors le système à son environnement.
Voir aussi la section [contexte].
Un diagramme d'état peu modéliser les différents modes et les événements qui produisent les changements de mode.
Mérite une section ??
Reprendre ici les questions des chapitres (à organiser en fichiers!).
Un quizz en ligne est disponible ici (me contacter pour le mot de passe).
En voici une capture d'écran :
L’ensemble des questions du quizz a été généré à partir de ce fichier quizz (qui contient les réponses).
Voici un petit exercice (en anglais pour l’instant, désolé) pour changer :
seq
Un point sur les évolutions de SysML.
Quelques exemples de sujet propice au développement SysML.
Cette Frequently Asked Question a été construite par expérience, en regroupant les questions des étudiants durant mes différentes interventions. J’ai aussi ajouté des questions souvent rencontrées dans les journées organisés par SysML-France.
|
|
Voir aussi cette FAQ très bien faite. |
Cette FAQ peut servir de base à la révision d’examens (cf. aussi [Exos]).
Non. Le lien de containment est en fait une action qui place le "contenu" dans le
"contenant". Dans TOPCASED, le diagramme laisse les liens précédents à l'écran, mais dans
le modèle, c’est bien le dernier containment réalisé qui est pris en compte. Dans
la figure ci-dessous le lien A-C a été "dessiné" après celui B-C.
|
|
Ce "bug" provient du fait que le lien de containment n’est pas un lien de dépendance, mais plutôt une représentation graphique de la contenance. |
(En lien avec la question précédente)
L’organisation SysML des requirements est en fait un arbre. Pour réaliser ce "partage" certains utilisent un lien <<copy>> pour créer plusieurs copies d’un même requirement. Personnellement je n’aime pas cette solution.
<<satisfy>> entre exigences?Techniquement oui (<<satisfy>> étant dérivé de <<dependency>>), mais ça n’a pas beaucoup de sens que de dire qu’un besoin est satisfait par un autre. Il s’agit le plus souvent d’un lien <<deriveReqt>>.
|
|
Certaines méthodes utilise ce lien pour par exemple exprimer qu’une exigence cliente et satisfaite par une exigence système (comme la méthode Harmony). |
<<deriveReqt>> et <<refine>> ?La norme n’impose pas de sémantique précise à <<deriveReqt>>. Il y a généralement deux interprétations.
puissance moteur déduite (deriveReqt) depuis l’exigence sur l’accélération d’un véhicule.
Autre exemple respectant 1 mais pas 2 : "Le véhicule doit posséder 4 roues." est dérivé de "Le véhicule doit se déplacer sur route." En effet, un aéroglisseur répondrait aussi l’exigence initiale et n’a pourtant pas de roues.
Quant au <<refine>> il est utilisé pour indiquer qu’un élément de modèle (qui peut être lui-même un requirement) est un raffinement (au sens niveaux d’abstraction, du plus abstrait au plus concret) d’un requirement. Par exemple, un use case ou un diagramme d’activité peut être un raffinement d’une exigence fonctionnelle (textuelle par exemple).
<<trace>> ?Il est utilisé pour indiquer que l’on souhaite conserver un lien de traçabilité entre les éléments
(par exemple entre un élément de modélisation et un document). Il est recommandé d’utilisé une de ces
versions plus précises (<<deriveReqt>> ou <<satisfy>> par exemple).
Verson 1.3 et disponible à l’URL: http://www.sysml.org/docs/specs/OMGSysML-v1.3-12-06-02.pdf
(en lien avec la question précédente)
Les changements notables par rapport à la 1.2 concernent :
|
|
SysML v1.3 Revision Task Force dirigée par Roger Burkhart et Rick Steiner améliore de manière régulière la spécification en fonction des retours des utilisateurs. |
Quelques autres questions que je laisse à votre sagacité :
Dernière MAJ : 30/11/2012 - 13:40:32 CET
Document généré par Jean-Michel Bruel via AsciiDoc (version 8.6.8) de Stuart Rackham.
La version présentation a été générée en utilisant W3C HTML Slidy © de Dave Raggett, amélioré par Jean-Michel Inglebert.
Pour l’instant ce document est libre d’utilisation et géré par la Licence Creative Commons.
licence Creative Commons Paternité - Partage à l'Identique 3.0 non transposé.
Les références…
[FIO2012] Fiorèse S., Meinadier J., Découvrir et comprendre l’ingénierie système, AFIS 2012.
[HAS2012] Haskins C., SE Handbook Working Group, INCOSE Systems Engineering Handbook: Version 3.2.2, International Council on Systems Engineering, 2012.
[KAP2007] Kapurch S., NASA Systems Engineering Handbook, 2007 (pdf).
[REQ2012] Guide Bonnes Pratiques en Ingénierie des Exigences, AFIS 2012.
[Roques2010] Pascal Roques. SysML par l’exemple - Un langage de modélisation pour systèmes complexes. Eyrolles. a acheter ici.
[Sommerville1997] Ian Sommerville, Pete Sawyer. Requirements Engineering: A Good Practice Guide. Wiley, 1997.
[SysML] OMG. Systems modeling language version 1.3. Technical report, 2012.
[taoup] Eric Steven Raymond. The Art of Unix Programming. Addison-Wesley. ISBN 0-13-142901-9.
[Walsh1999] Norman Walsh & Leonard Muellner. DocBook - The Definitive Guide. O’Reilly & Associates. 1999. ISBN 1-56592-580-7.
|
|
Ressources
Les définitions ci-dessous sont regroupées à titre indicatif. Les sources utilisées sont :
|
Don’t Repeat Yourself : Un bon principe qui veut qu’on évite de répéter des tâches manuelles (comme les tests) en utilisant plutôt des scripts et des programmes.
International Council on Systems Engineering : une organisation fondée en 1990 pour faire avancer les technologies d’Ingénierie Système .
Integrated Product Team : une équipe classique en développement système.
Object Management Group : L’organisme international chargé des principales normes liés à l’objet (CORBA, UML, etc.).
Test Driven Development : Développements dirigés par les tests. On écrit les tests avant d'écrire le code. On travaille son code tant que les tests ne passent pas.
Technology Readiness Level : système de mesure employé par des agences gouvernementales américaines et par de nombreuses compagnies (et agences) mondiales afin d'évaluer le niveau de maturité d’une technologie (cf. Wikipedia).
System Modeling Language ™ : le langage de modélisation de systèmes maintenu par l’OMG.